Image handling

The wwwopac.ashx offers functionality for efficiently retrieving and safely storing images. Its high performance for retrieving, scaling and cropping of images for display in the Axiell Collections Media Viewer or for thumbnail display in the Result set view for a search result is accomplished by not resizing the images to be retrieved for every request, but by reducing or enlarging the image only when first requested, and then saving the result in a cache folder so that for a following identical request next time a ready-made resized image can be retrieved. So the use of wwwopac.ashx for retrieving images is most useful if the images to which you link in your (museum) visual documentation records are pretty large files. For use in thumbnail displays, the image handler will scale those images on the server or it'll retrieve earlier created thumbnails, which results in less data traffic on your network, it lightens the workload of the Collections core software en also diminishes memory use of the work station enormously.
You can also use this functionality to directly and safely store images linked to in a visual documentation record, in an Axiell Collections SQL database, although you can store images in the file system as well.

Since release 3.3.0, the WebAPI started caching automatically created thumbnails in their original file format instead of in the .bmp format that was used before that. The advantage being that any metadata in the original file could be preserved mostly (while .bmp cannot store that metadata). A disadvantage would be that if you had always created all possible cached images in .bmp format in advance so that the WebAPI wouldn't lose performance during image retrieval actions by having to create a thumbnail in cache during such retrieval when it didn't exist yet, that performance gain would be lost. That issue was fixed in 3.3.1.1671. On image retrieval, the WebAPI now first checks if a cached image in the requested size is present in the .bmp format already and then retrieves that copy. Only if it isn't present in .bmp format it will check if it is present in the original file format and will retrieve that if found. The WebAPI will only create a new cached image if doesn't exist in either .bmp format or the original format: in that case it will create a cached image with the original file format. If you'd like all your cached images to contain as much metadata from the original image as possible, then clear your cache folder, so that the WebAPI can't use any cached .bmp files anymore and will create new cached images in their original file format when requested.

To be able to work with images, you'll first have to configure the images server. Click here for information about how to configure the images server in the adlibweb.xml file.
The two WebAPI functions for retrieving and respectively storing images, are getcontent and writecontent.

Instead of just using the file name of the image to retrieve, you may precede it by a partial path to a sub folder of the main images folder, when applicable. You may also use a full URL pointing to an image file, although in that case resized images won't be cached by wwwopac.ashx so you won't profit from the performance benefits otherwise provided by the caching of images.

Note that during the development phase of this functionality, there was talk of separate software named Image Handler which could have been used alongside wwwopac; however, the relevant functionality is now only available as part of wwwopac.ashx.